home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19960425-19960715 / 000206_news@columbia.edu _Wed Jun 5 22:18:48 1996.msg < prev    next >
Internet Message Format  |  2020-01-01  |  3KB
  1. Return-Path: news@columbia.edu
  2. Received: from apakabar.cc.columbia.edu (apakabar.cc.columbia.edu [128.59.35.159]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with ESMTP id WAA26218 for <kermit.misc@watsun>; Wed, 5 Jun 1996 22:18:48 -0400 (EDT)
  3. Received: (from news@localhost) by apakabar.cc.columbia.edu (8.7.5/8.7.3) id WAA22678 for kermit.misc@watsun; Wed, 5 Jun 1996 22:18:46 -0400 (EDT)
  4. Path: news.columbia.edu!lamont.ldeo.columbia.edu!zombie.ncsc.mil!news.mathworks.com!newsfeed.internetmci.com!news.ac.net!news.serv.net!news.alt.net!news1.alt.net!news.aros.net!news.cs.utah.edu!cc.usu.edu!jrd
  5. From: jrd@cc.usu.edu (Joe Doupnik)
  6. Newsgroups: comp.protocols.kermit.misc
  7. Subject: Re: Kermit arp problem
  8. Message-ID: <1996Jun4.170152.81491@cc.usu.edu>
  9. Date: 4 Jun 96 17:01:52 MDT
  10. References: <31b3b0e4.8632940@news.onramp.net> <DsHGF6.7yL@echelon.nl>
  11. Organization: Utah State University
  12. Lines: 40
  13.  
  14. In article <DsHGF6.7yL@echelon.nl>, kees@echelon.nl (Kees Hendrikse) writes:
  15. > In <31b3b0e4.8632940@news.onramp.net> saleh@onramp.net (Saleh W. Igal) writes:
  16. > 
  17. >> In <4ndec3$skd@epx.cis.umn.edu>, mill0440@gold.tc.umn.edu mentioned a
  18. >> problem with arp using Kermit's protocol stack on ODI -- I'm seeing
  19. >> almost exactly the same thing.
  20. > (..) 
  21. >> If anyone else has seen this problem, do you see any common factors?
  22. > 
  23. > A few years ago (when MSkermit 3.13 was just in beta) I experienced a
  24. > problem that looked remarkedly like yours. They only anomaly I could find
  25. > at the time, was that kermit seemed to choke on ARP-responses that were
  26. > 78 octets long, instead of the expected 60 octes. The work-around we used
  27. > was to add odipkt to the stack and let kermit run over the packet-driver
  28. > interface. We still use this trick if we can't get kermit to talk to a
  29. > Unix host straight over ODI.
  30. > 
  31. > I'm still not sure if this is a Kermit-problem or an ODI problem.
  32. > 
  33. > -- 
  34. > Kees Hendrikse                               | email:     kees@echelon.nl
  35. >                                              |
  36. > ECHELON consultancy and software development | phone: +31 (0)53 48 36 585
  37. > PO Box 545, 7500AM Enschede, The Netherlands | fax:   +31 (0)53 43 37 415
  38. --------------
  39.     It's in Kermit. The ODI portion which receives ARP packets expects
  40. either packet length from ODI (early MLIDs did not do it because it was
  41. not in the ODI spec at that time) or it will calculate a buffer size from
  42. the peek-ahead contents of the packet. In the latter case it means ODI will
  43. be prevented from delivering a too-long packet into the buffer provided by
  44. Kermit. Too-long ARP packets are broken.
  45.     The Packet Driver dodge eliminates my ODI code and hence permitted
  46. delivery. That is not a solution to broken packets but better than nothing. 
  47. It's not a bug in Kermit.
  48.     There are other gotcha's on the net too. A number of System 5 based
  49. Unices seem to go mute when their default route ARP cache entry is not 
  50. refreshed from outside; they can't respond. What's true for the default route 
  51. is also probably true for other routes in the cache. The problem at hand is
  52. not of this kind, however, and I await further word from the correspondent.
  53.     Joe D.